Computer applications generate and submit logging information to record events (e.g., errors or warnings). Conventionally, applications write logging information to files, databases or the syslog. The syslog is a standard for sending log messages in an Internet Protocol (IP) network but is difficult to process due to lack of structure. Files often do not have a well-defined structure, too. Databases generally provide a fixed structure for logging information such as audit logs. However, data in the audit logs often varies significantly from one situation to another. Databases usually do not have a clear definition for each data field where the definition can apply to all possible situations. Therefore, a database may end up in a situation where half of the fields are empty and most of the data has to be jammed into a few fields.
Generally, conventional event logging techniques are unable to reliably extract information from free form strings. One of the problems in the existing logging interfaces is that they permit application to send event messages in free form. This lack of structure in the messages makes analysis of the log data stream extremely difficult to reliably interpret. With the various formats that are conventionally used for logging information, it is also difficult to collect the logging information, merge and forward it to a centralized remote location for compliance and forensic inspections.
Conventional event logging techniques are also unable to dispatch data to multiple destinations. An application developer can specify one destination for the data related to an event. However, in some scenarios, an application developer may wish to send the same event data to different destinations that serve different purposes (e.g., logging, debugging and audit). To send event data to different destinations for logging, debugging and audit trails, an application developer usually needs to deal with multiple different interfaces and multiple different ways of generating information from the application.
Additionally, conventional applications usually select a logging interface such as the syslog or files for convenience during the developmental time. As the development of the application matures, an application developer may want to change the logging destination to a more advanced alternative. An application developer may also want to write the logging information into a file that is human readable. Moreover, when a logging destination fails, an application developer may want to write the logging information into a backup destination. However, modifying an application to change its logging destination and data formatting can be time consuming and error prone.